How did you get these translations? Are these just AI translated?

I was thinking of at some point allowing the AuthUIProvider to just accept a "locale" prop and set the translations automatically, and bundle a ton of major language localizations with the package

@daveycodez Yes these are AI translations FTM

I was thinking of at some point allowing the AuthUIProvider to just accept a "locale" prop and set the translations automatically, and bundle a ton of major language localizations with the package

Nice idea, in order to bundle size small, maybe it can be exported in a treeshake ready way, not just all in one

How much are localization strings really adding to the Bundle 🤔 just a bunch of strings I can’t imagine it’s that heavy? I’ll be doing some bundle analyzation soon across the board.

Anyway which AI did these come from? GPT? Maybe it’d be better to have a script that creates these files in the beforePublish script, so any localization strings automatically get translated. And then we can just provide an array of language codes to that script.

My concern with this as is is that it will be missing new strings and needs to be manually managed. An automatic system on before publish would be perfect. And just use Open AI key from .env to do it. At least until the locale prop is supported natively

The other thing is I'm working on a new Error Pages PR and it's going to change all of the localization keys from camel case to all caps snake case to match Better Auth error codes format, so these would need to be updated to match those as well when that's ready. An automatic generation script on build would definitely be ideal

On the official Better-UI community plugins page, there is a multilingual plugin called better-auth-localization. I'm currently using it in my app, and all messages from the backend are translated into the user's language. However, even if the backend returns the messages in any language, better-auth-ui keep ignoring them and uses en as the default, as shown in the example below:

I noticed that, strangely, if I pass null to any translation key in localization prop on <AuthUIProvider />, it begins to use the backend message. See below:

For UI translations, I believe the localization prop is sufficient, since many i18n libraries can easily solve this issue.

For error message translations, a new prop on <AuthUIProvider /> like { useBackendErrorMessages: true } that forces a direct fallback to this line:

That change can solve this localization feature with minimum effort and closes these issues: #85, #221, #98, and #96.

@daveycodez What do you think? If you agree, I can open a PR with this change and an example in docs about how to use with better-auth-localization plugin.

Make the prop called localizeErrors (defaults to true) and sure go for it, I'll merge it no prob

For error message translations, a new prop on <AuthUIProvider /> like { useBackendErrorMessages: true } that forces a direct fallback

Done: #261

I'm not ready to maintain these local translations at this time, there is a solution I am cooking in the meantime with v4, stay tuned for that.